Encore une faille locale dans le noyau Linux, encore une preuve de concept publiée dans la foulée. PinTheft n’expose pas toutes les distributions de la même façon, mais les systèmes concernés ont tout intérêt à ne pas remettre le patch à plus tard.

À peine le temps de souffler, PinTheft rejoint la liste des failles root exploitables qui secouent Linux. © Imagentle / Shutterstock
À peine le temps de souffler, PinTheft rejoint la liste des failles root exploitables qui secouent Linux. © Imagentle / Shutterstock

Le noyau Linux n’avait pas besoin d’une nouvelle casserole, mais PinTheft s’invite quand même avec son exploit sous le bras. D’après les travaux de V12, cette faille locale d’élévation de privilèges corrigée plus tôt ce mois-ci peut permettre à un attaquant d’ouvrir un shell root sur les systèmes vulnérables, principalement sur Arch Linux. Son exploitation dépend de plusieurs prérequis techniques, mais la disponibilité d’un code prêt à l’emploi relève le niveau d’urgence pour les machines qui n’ont pas encore été mises à jour.

BitdefenderBitdefender
8.4/10

Offre partenaire

La solution tout-en-un pour protéger votre entreprise

Votre petite entreprise a de grandes ambitions. Protégez-là contre les pirates. Et développez sereinement votre activité !

Offre partenaire

Une faille dans le module RDS du noyau Linux

PinTheft se niche dans RDS, pour Reliable Datagram Sockets, une composante réseau du noyau Linux utilisée dans des environnements spécialisés pour faire communiquer plusieurs machines entre elles. D’après l’analyse publiée par V12, le problème concerne le chemin d’envoi zerocopy, une méthode conçue pour transmettre des données sans les recopier plusieurs fois en mémoire.

Pour bien saisir de quoi il retourne, il faut savoir que lorsqu’un programme demande au noyau d’envoyer un bloc de données, celui-ci peut soit en faire une copie interne avant transmission, soit travailler directement à partir des zones mémoire déjà utilisées par ce programme grâce au zerocopy. Le noyau repère alors les pages mémoire concernées, c’est-à-dire les petits blocs où sont stockées les données à envoyer, puis les verrouille temporairement pour éviter qu’elles soient modifiées, libérées ou déplacées pendant l’opération. Si l’opération se déroule comme prévu, ces pages sont ensuite déverrouillées, et le noyau efface la liste temporaire qui les associait à l’envoi en cours.

En revanche, si une erreur survient après le verrouillage d’une première série de pages, RDS les libère bien pour annuler l’opération, mais n’efface pas complètement leur trace dans cette liste temporaire. Lors du nettoyage final, le noyau les traite alors une seconde fois, comme si elles faisaient encore partie de l’envoi en cours.

Ce second passage dérègle le suivi de la mémoire. En provoquant l’erreur à répétition, l’exploit publié par V12 parvient à reprendre la main sur une page mémoire qu’il ne devrait plus pouvoir manipuler, puis à s’en servir pour réécrire le cache de pages, et ouvrir un shell root, soit une interface de commande exécutée avec les privilèges les plus élevés sur la machine vulnérable.

Un exploit public, mais un périmètre plus étroit qu’il n’y paraît

PinTheft étant une faille locale, un attaquant doit donc déjà disposer d’un accès à la machine, via un compte compromis, un malware ou un environnement partagé, pour pouvoir en abuser.

Mais même dans cette situation, l’exploitation ne fonctionne pas sur n’importe quelle installation Linux. Elle suppose que le module RDS soit chargé, ce qui est par défaut le cas sur Arch Linux, que io_uring, l’interface du noyau dédiée aux entrées-sorties asynchrones, soit disponible, qu’un binaire SUID-root (programme autorisé à s’exécuter avec les droits root même lorsqu’il est lancé par un compte moins privilégié) lisible soit présent sur le système, et que la machine repose sur une architecture x86_64, seule cible du payload publié par V12.

La surface d’exposition est donc limitée, mais elle n’autorise pas à temporiser sur les machines concernées. PinTheft a déjà été corrigée, son fonctionnement est documenté, et un exploit public circule désormais. La priorité consiste à installer les dernières mises à jour du noyau, en particulier sur les systèmes Arch Linux exposés par défaut au chargement de RDS. En attendant un redémarrage ou une fenêtre de maintenance, V12 recommande de décharger les modules rds_tcp et rds, puis d’empêcher leur chargement via modprobe.d. De quoi couper le chemin d’exploitation connu, sans se dispenser du correctif.

À découvrir
Quelles sont les meilleures distributions Linux ? Comparatif 2026
Comparatifs services
Foire aux questionsContenu généré par l’IA
Qu’est-ce qu’une faille locale d’élévation de privilèges (LPE) dans Linux ?

Une LPE (Local Privilege Escalation) est une vulnérabilité qui permet à un utilisateur déjà présent sur la machine (compte limité, service compromis, malware) d’obtenir des droits plus élevés, jusqu’à root. Elle ne sert généralement pas à « entrer » dans un système à distance, mais à franchir une barrière de permissions une fois un premier accès acquis. Le risque dépend donc beaucoup du contexte : postes multi-utilisateurs, serveurs avec comptes applicatifs, conteneurs, ou environnements partagés. Quand un exploit public existe, la fenêtre de risque se réduit, car l’attaque devient plus simple à reproduire. Dans Linux, ces failles touchent souvent des chemins noyau liés à la mémoire, au réseau ou aux entrées-sorties, où une erreur de gestion suffit à casser l’isolation.

À quoi sert le module RDS (Reliable Datagram Sockets) dans le noyau Linux, et pourquoi son chargement compte ?

RDS est un composant réseau du noyau Linux destiné à des échanges efficaces entre machines, surtout dans des environnements spécialisés (par exemple certains clusters). Tant que le module n’est pas chargé, le code concerné n’est pas actif et la surface d’attaque associée reste très réduite. À l’inverse, lorsqu’il est chargé par défaut ou via une dépendance, il expose des interfaces noyau supplémentaires que des programmes locaux peuvent solliciter. C’est pour cela que la présence/activation du module devient un prérequis important dans l’exploitation d’une vulnérabilité qui s’y trouve. En pratique, désactiver temporairement un module vulnérable peut “couper” un chemin d’attaque, mais ne remplace pas une mise à jour du noyau.

Que signifie « zerocopy » dans le noyau Linux, et en quoi une erreur de nettoyage peut mener à un accès root ?

Le « zerocopy » est une technique qui évite de recopier plusieurs fois des données entre espace utilisateur et noyau lors d’un envoi réseau : le noyau travaille directement avec des pages mémoire déjà remplies par l’application. Pour garantir l’intégrité, ces pages sont « épinglées » (verrouillées temporairement) et suivies dans des structures internes le temps de l’opération. Si un chemin d’erreur libère des pages mais laisse des références résiduelles dans la liste de suivi, le noyau peut ensuite retraiter ou relibérer des objets déjà rendus, ce qui corrompt la gestion mémoire. Ce type de désynchronisation ouvre la porte à des primitives d’exploitation (réutilisation de pages, écriture dans des zones inattendues) qui peuvent être enchaînées jusqu’à l’exécution de code avec les privilèges root. C’est une mécanique classique des LPE : une petite incohérence dans le suivi des ressources finit par casser l’isolation entre utilisateurs.